For the 2018 FRC season, I was part of the team in charge of the code architecture of the robot. Our team wanted to make sure that our architecture was especially safe and good at error handling so that our robot would not crash during the competition game. This was an issue in our pre-season competition, where our robot sometimes didn’t run at all during the match due to the robot not detecting our Jetson or other issues.
In previous years, we had used the same general architecture, with the following classes:
- Robot: contains all objects, and the code for autonomous and teleop modes
- RobotMap: contains the mapping of motors and sensors
- SensorThread: continuously updates and records values from sensors
- OI: contains code for controls/joysticks
- Database: contains important numbers and retrieving sensor data
- Subsystems: representations of independently controlled parts (arms, drivetrain, shooter)
- Commands: actions of subsystems
We wanted to keep the general architecture, but write new classes to support more logging and error handling. Here are the new classes that we wrote:
- TrackingRobot: more logging, try-catch around functions, a new thread for Jetson
- TrackableSubsystem: logging, getting state of subsystems, and function to run code after stopping
- Devices: contains all hardware devices on robot
- Controls: replaces OI to avoid RobotBase error
- UtilityServerSocket: socket used to connect to Jetson server
We had to give a presentation to the other members of the software team about it so that they could implement their features with little difficulty.
After our work in architecture, we also worked on robot diagnostic code. With this project, we wanted to diagnose each device of the robot to ensure that the robot is functioning well before games. We would run the diagnostic code before each round to ensure motors, sensors, and other components are working. If there are any problems, we can quickly fix them before the match, and not be surprised during the match.
This project was fairly simple, as we only had to create a list of things on the robot (ie. how many talons/gyro/etc.), and test each item on the list. We were able to complete the diagnostic code, with lots of logging on the status of each component, and it was used heavily during competitions between matches.